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Abstract. This paper is the long version of the extended abstract with the same 
name (9). We describe in detail the algorithm to generate verification conditions 
from statechart structures implemented in the iState tool. This approach also sug- 
gests us a novel method to define a version of predicate semantics for statecharts 
analogous to how we assign predicate semantics to programming languages. 
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1 Introduction 

The statechart formalism, proposed by Harel (7| as an extension of conventional fi- 
nite state machines, is a visual language for specifying reactive systems. It addresses 
the state explosion problem of state transition diagrams when modeling systems with 
parallel threads of control by introducing the concepts of hierarchy, concurrency, and 
communication. 

The iState tool translates statecharts into various programming languages, currently 
the Abstract Machine Notation (AMN) of the B method CD, Pascal, and Java. The 
translation is based on a definition of statecharts in terms of an extension of Dijkstra's 
guarded commands 11511611 . This work demonstrates a novel statechart verification ap- 
proach using state invariants that has been added to iState. 

2 Invariants 
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Statecharts allow executable specifications to be derived from user requirements. We 
propose to supplement a statechart specification by invariants. These are attached to 
states and specify what has to hold in a state configuration. Invariants are also derived 
from the requirements. They are not meant for execution, but they allow the statechart 
specification to be cross-checked. By themselves, statecharts do not lead to opportuni- 
ties for consistency checks beyond well-formedness; invariants address this limitation 
and give a way of documenting the "purpose" of states. 

Formally, invariants are predicates over global variables, like x in the example be- 
low, and states (state tests): 



U(x>6) 



R{x>l) 



S(x< 100) 



E[x^5Mx:-- 
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The definition of statecharts in 0151161 translates states into variables and events into 
(nondeterministic) operations, in which use of the independent (parallel) composition 
of statements is made; the parallel composition operator is essential for translating 
events with transitions in concurrent states. Using AMN, the states of the previous stat- 
echart are translated to variables root G {R, U}, r G {S}, a G {M} and b G {A^} and the 
event E is translated to: 

E = if root = R then 
if r = S then 
if x 7^ 5 then 

x:=x+10 || root := U \\ a := M \\ b := N 
end 
end 
end 



Let si: State — > Condition be a function that assigns to each state the invariant specified 
by the designer, or true if none is specified, together with a test for being in that state. 
For example: 



si(S) = (r = SAx< 100) 
si(U) = (root = U Ax > 6) 



By the hierarchical structure of statechart, being in a state also means being in all of its 
ancestor states, in exactly one of its child states if the state is an XOR state, and in all of 
its child states if the state is an AND state. Hence, we have to compose state invariants 
together to create the accumulated invariant ai(s) of state s. For example: 

ai(S) = (root = RAx> \)A{r = SAx< 100) 
ai(U) = {mot=UAx>6)A((a = MAx< 111) A (b = NAx ^ 15)) 

Formally, let Basic, XOR, AND be disjoint subsets of the set State. The accumulated 
invariant at State — ► Condition is defined with the help of the child invariant ci: State 
— > Condition as follows: 

!si(s) A <g> ci[children [{s}}} if s G XOR 
si(s) A f\ci[children[{s}]] if s G AND 
si(s) if s G Basic 

ai(s) = f\si\parent + [{s}]] Aci(s) 

Here, children[{s}] denotes the set of all child states of a state s and parent + [{s}] de- 
notes the set of all ancestor states of s, where parent is the inverse of the child relation, 
parent = child~ l 11511611 . The operator (g) stands for xor. The definition reflects the 
meaning of XOR and AND states. 
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3 Event Codes and Verification Tuples 

For each transition E[guard]/ action from state S to T, where action is a statement that 
may read and write to global variables, may include state tests, and may broadcast other 
events, a verification condition is generated: 

{ai(S) A guard} action {ai(T)} 

In the case of broadcasting in action, the broadcast is replaced by a call to the corre- 
sponding operation. In the case of transitions in concurrent states on the same event E, 
a combined transition is considered. In the example, the verification condition for event 
E is: 

{{root = RAx> l)A(r = SAx< 100) Ax ^ 5} 
x:=x+ 10 || root:= U \\ a := M \\ b := N 
{(rvot=UAx>6)A((a = MAx< 111) A {b = NAx^ 15))} 

Hence, our goal is to automate the generating verification condition process. However, 
before doing so we need to have data structures to store and manipulate the verification 
conditions efficiently. 

Using the algorithm discussed in 11511611 . we map each statechart data structure into 
nondeterministic operations which is represented using an abstract syntax tree (AST). 
The AST of intermediate language is stored using the data type EventCode 

EventCode = Identifier ■+> Statement 

where S -b- T denotes the set of partial function from S to T. 

Let ¥(S) and seq(S) denote the types power set of S and finite sequences of S re- 
spectively. Also let S <-» T denote the set of relation from S to T. Each Statement is then 
defined as a recursive data type 

Statement = StateAssign State 

| Assignment Identifier Expression 

| Beast Identifier 

| Guard Condition <-> Statement 

| Par seq(State?nent) 

| Seq seq(Statetnent) 

| Skip 

where: 

- StateAssign State: denotes the state assignment node. 

- Assignment Identifier Expression: denotes assignment node and the left hand side 
of the assignment is an identifier and the right hand side is an expression. 

- Beast Identifier: denotes a broadcasting of an event whose name is represented 
using an identifier. 
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- Guard Condition <-> Statement: denotes an alternative choice where each choice 
is guarded using a condition. Notice that we use Condition <-> Statement to empha- 
size the possible non-determinism. When several conditions are true at the same 
time, a choice is made non-deterministically. 

- Par seq(Statement): denotes the parallel composition of a sequence of statements. 
Due to the commutativity of parallel composition, we might use a set of statements 
instead of sequence. However, we decide to use sequence here only for the sake of 
determinism. 

- Seq seq(Statement): denotes the sequential composition of a sequence of state- 
ments. 

- Skip denotes the skip statement. 

The type Condition can either be a state test or a predicate, which is defined as 
following 

Condition = StateTest State 

Predicate Expression 

Notice that using a functional language like syntax to define Statement and Condition 
allows us to employ pattern-matching on these data types when presenting our algo- 
rithms. 

We then generate verification conditions from EventCode data structure. This will 
be done by analyzing the structure of EventCode to generate local verification condi- 
tions and composing them together suitably to produce the final verification conditions. 
We treat all of these verification conditions uniformly using the notion of verification 
tuple, which we think to be a more suitable representation of Hoare's triple for our 
verification purpose. The verification tuple type is define as following: 

VTuple = P(State) x Expression x Statement x F(State) 

where for each (s,g,a,t) € VTuple we have: 

- s denotes the set of source states of the transition, 

- g denotes the guard condition of the transition, 

- a denotes the statement which changes the states of global variables (including state 
variables), 

- t denotes the set of target states of the transition. 

Notice that each (s,g,a,t) £ VTuple is converted into the following verification condi- 
tion 

{/\ai[s]Ag}a{/\ai[t}} 

which is verified as a normal Hoare's triple. However, using sets of source of target 
states gives a more optimal way of composing verification conditions together. This also 
helps us avoiding redundancy when generating accumulating invariants due to states 
having common ancestors. In other words, we use the following more efficient way 
to calculate the acumulated invariant of a state set. Let the state set closure function 
cl : F(State) -» f {State) be defined as following 

cl(ss) = [_J{pare77f*[{s}] | s G ss} 
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where R* denotes the reflexive transitive closure of the relation R. We define the set 
accumulated invariant function sai : ¥(State) — > Condition as follows: 



For convenience, we let ast : String — ► Expression U Statement denote the mapping 
from a String to its AST. Hence, the verification condition discussed in our example 
previously can be expresses using the following VTuple: 

({R,S},ast("x^5"),ast("x :=x+W || root := U\\a:=M \\ b := N"),{U,M,N}) 
4 Invariant Verification Algorithm 

Before presenting the algorithm for generating verification tuples, we need several aux- 
iliary functions. We divide Condition into StateTest and Predicate. The state test con- 
dition StateTest are generated by EventCode generators using the algorithm in II15I16I . 
Hence, we let Predicate denote the transition guards supplied by users. To distinct these 
two cases, we use the following function 

c2tuple : Condition — > VTuple 

c2tuple StateTest s = ({s} , true , Skip , 0) 

c2tuple Predicate e = (0, e, Skip,®) 

Considering the following example where you have: 



For simplicity, we suppose these two statements are simply user statements without 
state test or state assignment. Then the statement if ci then si else S2 end corresponds 
to the verification tuple set 



Since these two if statements are composed in parallel, we the resulted parallel product 
verification tuple set for the whole statement is: 




if s E AND UXOR A children(s) G cl(ss) 



if c\ then s\ else S2 end || if C2 then S3 else S4 end 



{(0.C1, SI, 0),(0, -C1,J 2 ,0)} 



and the statement if ci then S3 else S4 end corresponds to the set 



{(0,C2,S 3 ,0),(0,-C 2 ,S4,0)} 



{(0,eiAe 2 ,si||s3,0),(0,->ci Ac 2 ,s 2 ||s3,0),(0,-.ci Ac 2 ,s 2 ||s3,0), 
(0,^ciA-.C2,s 2 ]|s 4 ,0)} 
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The more general case including state tests are tackled using the following functions: 

parProd : seq(¥ (VTuple)) -> ¥(VTuple) 
parProd [] = 
parProd [s] = s 

parProd [s\,...,s n ] = {concatl([t\, . . . ,/„]) | (t\, . . . ,/„) E si X . . . X s n } 

concatl : seq(VTuple) — > VTuple 
concatl [] = (0, true, Skip,®) 

concatl [(si,gi,ai,ti) | i= l..n] = {{J" =l Si,/\" =l gi,Par [ai, . . . ,a„],U"=i f i) 

This function parProd is used very often in our implementation and it helps to simplify 
the implementation substantially. 

Similar to the case of parallel composition is the case sequential composition. For 
example, an event code 

if ci then si else S2 end ; if C2 then 53 else 54 end 

will be translated into the following verification tuple set 

{(0,ci Ac 2) Ji;J3,0),(0,->ci Ac 2) J2;*3,0),(0,->ci AC2,S 2 ;.S3,0), 
(0,-iCi A- 1 c 2 ,s 2 ;s 4 ,0)} 

Since the statements must be composed sequentially, the functions are implemented as 
following. 

seqProd : seq{F (VTuple)) -> P(VTuple) 
seqProd [] = 
seqProd [s] = s 

seqProd [s\,.. .,s„] = {concat2([t\, . . . ,t„}) \ (t\, . . . ,t„) G si X . . . X s„} 

concat2 : seq(VTuple) — > VTuple 
concat2 [] = (0, true, Skip,®) 

concat2 [(*,•, g h a u *;) | «'= l..n] = (ULi^ALig^? [ai, . . . ,a„],U"=i*i) 

We then define a function s2tuples which maps each statement node to a set of 
verification tuples. Using pattern-matching, the function s2tuples can be defined as fol- 
lowing: 

s2tuples : Statement — > P(VTw/?/e) 
s2tuples StateAssign s = {(®,rue,StateAssign s, {s})} 
s2tuples Assignment i e = {(0, true , Assignment i e,0)} 
s2tuples Beast i = {(0, true, Beast i,®)} 

s2tuples Guard r = {J{parProd([{c2tuple(c)},s2tuples(s)]) \ (c,s) 6 c} 
s2tuples Par ss = parProd( [s2tuples(s) \ s <— ss] ) 
s2tuples Seq ss = seqProd([s2tuples(s) \ s <— ss]) 
s2tuples Skip = (0, true, Skip,®) 
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Hence, we can construct a global verification tuple map for all events using the fol- 
lowing function: 

vtupleMap : EventCode — > (Identifier —>P(VTuple)) 
vtupleMap ec = s2tuples o ec 

where the operation o denotes the usual function composition, i.e,fog(x) —f(g(x)). 

Since each verification tuple (s,g,s,t) £ \Jran(ytupleMap), the action s might still 
contain event broadcasting. We deal with these event broadcasts similarly to the case of 
parallel composition of event codes. We first apply topological sorting algorithm ITOl 
on vtupleMap(ec) to obtain a sequence 

tss = [(e\,s\),. . . ,(e, u s n )] <E seq(Identifier x¥(VTuple)) 

such that for each (e,,s,), the verification tuple set s; contains the actions that board- 
cast only the events in the set {ei, . . . ,e ( _i}. We can always obtain such a list with the 
assumption that we don't allow circular broadcasting [3j. We next define a function to 
collect and filter the boardcasts from the action of a verification tuple as following: 

collectBcast : Statement — > F '(Identifier) 

collectBcast Beast i = {/} 

collectBcast Guard {(c,-,i,) | i = l..«} = U" =l collectBcast(si) 

collectBcast Par [si, ... ,s n ] = U"=i collectBcast(si) 

collectBcast Seq [s\ , . . . ,i„] = Uf=i collectBcast(sj) 

collectBcast s = 

filterBcast : Statement — > Statement 

filterBcast Beast i = Skip 

filterBcast Guard r — Guard {(c,s) | (c,s) G r A^isBcast(s)} 

filterBcast Par ss = Par [s \ s <— ss A ~^isBcast(s)] 

filterBcast Seq ss = Seq [s \ s <— ss A ~^isBcast(s)] 

filterBcast s = s 

isBcast : Statement — > Boolean 
isBcast Beast _ = true 
isBcast _ = false 

In our real implementation, we filter and collect broadcasted events at the same time 
for the sake of efficiency. We let ^ denote the sequence concatenation operator. Then 
the process of translating verification tuples with broadcasting to ones without board- 
casting is implemented as the following functions: 

vtupleNoBcast : (VTuple x seq(Identifier x P(VTuple))) — > P(VTuple) 
vtupleNoBcast ((s,g,a,t) , tspre) = 
if (collectBcast = 0) then 

parProd( [{ (s,g,filterBcast(a) , t ) }] ~ 
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[sj | (e,-,,Sj) <— tspre Ae; G collectBcast(a)]) 

else 
end 

The function vtupleNoBcast takes a pair of verification tuples and fspre as inputs. The 
argument tspre represents the set of prefix of tss where all boardcasting are already ex- 
panded. Since we tss is already topologically sorted according to the dependencies of 
boardcasting, the action a only broadcasts the events defined in tspre. Hence, we apply 
the function parProd on the list consisting of the input verification tuples with all the 
broadcasts filtered and the part of tspre chosen according the set of events that the action 
a broadcasts. 

The rest of the elimination of broadcasting is defined in the next two functions. 
We define a function vtupleSetNoBcast which is similar to vtupleNoBcast but apply on 
verification tuple sets instead. 

vtupleSetNoBcast : (F(VTuple) x seq(IdentifierxP(VTuple))) -> P{VTuple) 
vtupleSetNoBcast ({v,- | i = l..n} , tspre) = \J[ = yVtupleNoBcast(yi,tspre) 

We then define the desired function vseqNoBcast which can now be applied to the 
topological sort list tss to expand the event broadcasting to suitable verification tuple 
sets. This function is defined as following: 

vseqNoBcast : stq(Identifier x¥(VTuple)) — > seq(Identifier x¥(VTuple)) 
vseqNoBcast [] = [] 

vseqNoBcast [(e,-,j,-) | ; = l..«] = tspre~[(e n ,vtupleSetNoBcast(s n , tspre))] 
where tspre = vseqNoBcast([(ej,Sj) | i = \..n — 1]) 

Hence, we use the result vseqNoBcast(tss) to generate the verification conditions. 

5 Predicate Semantics of Statecharts 

Our verification approach reveals a strong connection between a statechart transition 
and a verification tuple. This motivates us to provide a predicate semantic of statecharts 
instead of the traditional operational way in H8I13I1 II . We do so by introducing the 
functions for translating statecharts to verification tuples. These functions are very sim- 
ilar to the functions used in the previous section. In fact, we will use some auxiliary 
functions defined previously. 

We first need to provide the data structure used to represent statecharts. 

State = Basic Identifier 

| And Identifier x seq(State) 
| Xor Identifier x seq(State) x State x Transition 
where Transition is a five-ary relation defined as following: 

Transition = State x Identifier x Condition x Statement x State 
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This definition says a statechart state can be either 

- a Basic state with a state name, 

- a composite And state encoded by a state name and a sequence of parallel sub 
states, or 

- a composite Xor state encoded by a state name, a sequence of sub states, an initial 
state and a transition relation. 

Each transition is defined by its source state, triggering event, transition guard, action 
and target state respectively. 

We also use an event-centric approach by dealing with each event separately. Hence, 
we first define a function to return the restriction of a statechart with respect to a specific 
event. We use () to denote the empty identifier which indicate the "event name" of a 
spontaneous transitions. 

resStateEvent : (Identifier x Sate) — > State 
resStateEvent (_ , Basic id s) = Basic id s 

resStateEvent (e , And id [s,- | / = \..n]) = And id [resStateEvent(i,Sj) \ i = l..n] 
resStateEvent (e , Xor id seqs init t) 

= Xor id seqs init [(ss,e' ,c,a,ts) \ (ss,e' ,c,a,ts) <— t A (e' = eVe'= ())] 

We then need a function to return the verification tuple correspondent to the initializa- 
tion of a state due to the fact that each composite XOR state must have an initial state. 

initialize : State —>¥(Vtuple) 
initialize s = case s of 

Basic id s — > {(&, true, StateAssign s, {s})} 
And id [s{ \ i = 1 . .n] — > 

parProd([initialize(sj) \ i = 1. •«]"[{ (0, true, StateAssign s, {s})}]) 
Xor id [sj | ; = \ ..n\ init t — > 

parProd( [initialize (init)] ~ [{ (0, true, StateAssign *,{*})}]) 

This function initialize will always return a singleton set, since we enforce only one 
possibility to initialize a composite or basic state by disallowing some statecharts vari- 
ants 1151161 . However, for convenience the returned type of this function is P(Vtuple) 
to make it easier for composing verification tuples together in the intermediate compo- 
sition steps. In other words, it allows us to treat this case as a special case of parallel 
composition using the parProd function. 

The next step is to define a recursive function to generate verification tuples with 
respect to statechart data structure. The base case is the the case of basic states and the 
recursive cases deal with composite states. The most difficult problem is caused by the 
existence of spontaneous transitions in composite XOR states. We define the following 
two functions that take a child state of an XOR state and generate verification condi- 
tions. When there are spontaneous transitions, the function getNext invokes getSpon to 
search for the spontaneous transition going from the target states and generate verifica- 
tion condition for them and then compose the verification conditions together properly. 
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getNext : (State x Transition) — > ¥(Vtuple) 
getNext (s,tr) 

= {parProd([{({s},g,a,%)},getSpon(t,tr)]) \(s,id,g,a,t) G tr A id ^ ()} 

getSpon : (State x Transition) — > ¥(W tuple) 
getSpon (s,tr) = SUparProd([{(<d,G, Skip,®)}, initialize^)]) 
where 

5= {parPre>d([{(0,g,a,0)},ge/5pon(/,/r)]) \(s,id,g,a,t) e fr A id = ()} 
G = A{-£ I (s,id,g,-,J) £ tr A id = (}} 

The set S in function getSpon corresponds to the case the spontaneous transitions are 
taken and the condition G is the condition for non of the spontaneous transition from 
state s is taken. 

After having these two functions, the rest of the task of generating verification tuples 
from a statechart state restricted to one event is defined in the following function. 

s2tuples : State — > ¥(Vtuple) 
s2tuples s = case s of 

Basic id s — -> {({s}, true, Skip,®)} 

And id [sj \ i = l..n] — > parProd([s2tuples(si) \ i= l-.n]]) 
Xor id [sj | /= l..n] /n/f tr — > 5iU52 
where 

51 =U"=ige'Afo*(s ( -,?r) 

G = A{^| (_,«,_,_) GS} 

52 =parPro(i([{(0,G,5'A:/p,0)}]'^[52fM/7Ze5(5 ( )|/ = l..n]) 

To generate all the verification conditions of a statechart, we first collect the set of all 
events in a given statechart. For each event we use the function resStateEvent to get the 
restricted statechart to each event in the set and then apply the function s2tuples to the 
root of the statecharts. As a result of this process, we will get a map from event names 
to verification tuples exactly like the map vtupleMap previously. The branch statements 
and event broadcasting in the actions of verification tuples can be easily expanded out 
using the function s2tuples and vseqNoBcast defined in the last section. 

6 Implementation 

The iState tool currently uses the Simplify theorem pro ver )6 | to discharge the generated 
verification conditions because of its support of first order logic and linear arithmetic. 
Simplify also has arrays built in, though currently iState does not use them. We are 
working on extending iState with data types like arrays, rational numbers, and real 
numbers. In future, we also plan to extend the verification theory to timed transitions 

m. 



7 Discussion 
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Compared to the statechart verification approaches in H4I5I121 . we use an event-centric 
semantics of statecharts by looking at events as operations rather than data as in the 
original state-centric semantics (8). Instead of writing global temporal specification 
(say in CTL or LTL) separately, inspired by nested invariant diagram Q, invariants 
(safety properties) are attached to states. 

By attaching invariants to states and utilizing the guarded command representation 
of statecharts H15I16I . we arrive at a rather straightforward verification method. The 
approach generating verification conditions leads to many small "local" verification 
conditions and avoids some impossible configurations, compared to when specifying 
invariants on the global level. As many small verification conditions are easier to handle 
automatically than a few large ones, we believe that the approach can more easily scale 
up for the verification of large systems. 
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